As an example for exemplifying the present invention, it is referred hereinafter to mobile data transmission and data services, which are constantly making progress, and which lead to sophisticated communication network developments such as LTE/LTE-A systems.
In this regard, 3GPP Rel-10 is introducing a so-called Local IP Access (LIPA) functionality in E-UTRAN and UTRAN systems. Such feature enables the access of local IP networks from femto cells, which are called Home NodeBs (HNB) and Home eNodeBs (HeNB) in 3GPP specifications. An outline of an architecture solution is specified in 3GPP TS 23.401 and 23.060. In 3GPP Rel-11, such feature is to be enhanced with mobility support. The present description refers by mere way of example only to the terminology as adopted in those environments, but of course, the teaching outlined herein below will be applicable to other environments using different terminology. That is, a similar feature like LIPA can be established involving any terminal such as a UE, via any network transceiver device such as a HeNB, via any (local) gateway such as a LGW, towards any (local) IP network and/or PDN.
In Rel-10 the HeNB and the (single) Local Gateway (LGW), which provides the connectivity to the local IP network, are collocated. The HeNB sends the collocated LGW address to the MME/SGSN, and if the MME/SGSN decides to establish a LIPA connection, then it uses the provided address as the LGW address.
In the subsequent Rel-11, the LIPA feature is enhanced by allowing a standalone LGW and there can be more than one LGW in a local network. That is, a respective HeNB may have connectivity to plural LGW's rather than only to a single (collocated) LGW.
Therefore, in such scenarios, some mechanism needs to be specified how a LGW is selected for LIPA access.
3GPP TR 23.859 version 0.3, Section 5.2.2, describes already two basic options for LGW selection: a DNS (domain name server) based solution and a RAN (radio access network) based solution.
In the DNS based solution, LGW addresses are registered in a domain name server, DNS, of the network's operator and then the MME/SGSN performs a DNS query as it does in other cases with specific parameters: requested APN, Local HeNB Network identifier.
In the RAN based solution the H(e)NB sends a list of the available LGW addresses/identities and for each LGW, the APNs supported by the respective LGW to the MME/SGSN, and then for the specific APN requested by the UE, the MME/SGSN selects one appropriate LGW from that list.
In this regard, it is noted that in LTE (or E-UTRAN) the HeNB itself does not know the APN requested by the UE, as this information is transferred encrypted from the UE to the MME.
Therefore, the HeNB is not capable of finally selecting the LGW to be used for a requested connection.
The RAN-based solution, however, imposes a certain increased signaling on the interface between HeNB and MME/SGSN. Moreover, by furnishing all the information concerning the local network, i.e. on available LGW s and their supported access nodes, towards the MME/SGSN, the network topology is revealed to the MME/SGSN. If the local network constituted by one or more HeNB's is a company network while the MME is part of a public operator's LTE/UMTS network, this can raise security issues.
Thus, there is still a need for further improvement in terms of RAN based LGW selection.